I'm going to need to understand this a little better but the type-ahead.com site is down at the moment, so deferring.

The main issue is that for certain useful configurations of typeahead.js one needs to be able to put literal javascript (other than strings and numbers) into the configuration parameter. For an example, see the last demo at http://twitter.github.io/typeahead.js/examples/, which, to support templating of the completion items, requires something like:

$('#myinput').typeahead({
    // [..other stuff...]
   template: '<p><strong>{{value}}</strong> – {{year}}</p>',
   engine: Hogan
})

The patches in this pull request support that configuration via something like:

from defom.widget import literal_js, AutocompleteInputWidget
typeahead_config = {
    # ... other stuff ...
    'template': '<p><strong>{{value}}</strong> – {{year}}</p>',
    'engine': literal_js('Hogan'),
    }
form['myinput'].widget = AutocompleteInputWidget(datasets=typeahead_config)

The literal_js API doesn't particularly give me the warm fuzzies, but I haven't come up with anything better.

I haven't thought about it too hard, but something like this could also probably be used to support hairy configurations for select2 and TinyMCE as well.

The canonical way to do this in HTML 5. AFAIK this can be made to work with a JSON source.

@Themanwithoutaplan Could you elaborate a bit? It's probably that I'm dense, but I'm having trouble making sense of your comment.

@Themanwithoutaplan the implementation of list is lacking. 😞

Meanwhile a typeahead is useful. For a demo of a recent version of typeahead, see https://selectree.calpoly.edu/

@dairiki this can be done natively by the browser using the list attribute with a relevant source. A polyfill could be use to provide backwards compatibility.

@stevepiercy that's a nice widget. Be even nicer if it worked with the datalist element. Otherwise we'll spend most of our time chasing our tails. Native support, the new laggard that is Safari excepted, is pretty good.

@Themanwithoutaplan if by "pretty good" you mean "buggy", then I agree. 😉 Did you see the footnotes for datalist on caniuse? Those are pretty bad.

For deform_bootstrap the PR should be merged but I think a more generic datalist-based approach where the framework does the polyfill should be investigated.

For deform_bootstrap the PR should be merged

@Themanwithoutaplan do you mean this branch deform2? AFAIK, there is no deform_bootstrap.

a more generic datalist-based approach where the framework does the polyfill should be investigated.

I agree with this. Would you create new, separate issue with details?

As @stevepiercy mentions, typeahead has many more capabilities than (by my understanding, at least) HTML5/datalist: (even if browser support were not an issue) — things like callback/query based completion lists, fancy templatable completion listings.

This PR has to do with introducing a mechanism whereby these advanced features of typeahead may be configured through the deform widget. Stock deform has no trouble using typeahead with static completion lists and default completion formatting. In the context of this PR, whether or not HTML5 should be used for simple autocompleting inputs is a red herring.

@tseaver Reason for closing?

@dairiki sorry, guys.. I submitted an issue about the deform2 branch being dead and confusing so @tseaver deleted it. Can you resubmit this on the master branch?

@dairiki I've added this to the Deform 3.0.0 milestone. I'm preparing a release, now that I have PyPI maintainer access. Would you please be so kind to reopen this PR against master? Thank you!

@stevepiercy I do not see a github UI option to re-open this PR. (Perhaps that is because I am not the one who closed it? — that was @tseaver.) I will work on rebasing over the next couple of days. I guess I can just open a new PR if we can't figure out how to re-open this one...

PS: I am no longer using deform in an active project, but I am certainly willing to help get these old PRs merged if they are still pertinent.

@dairiki yeah, there is no option to reopen a PR against a deleted branch, specifically deform2, otherwise I would do it myself. We discovered only after the fact that GitHub has a footgun feature where it permanently closes PRs made to a specific branch when that branch is deleted. 🤦

I would be grateful for you opening the PR, and we can take it from there. I recently discovered that when someone opens a PR against a repo where I have write access, I can push commits to that person's branch in their repo and it updates the PR.

I've rebased my typeahead-datasets branch onto the current master. Unfortunately, there is an issue. I had been relying on a hack to support JSON-esque serialization of values containing literal javascript using json.JSONEncoder from python’s standard library. It seems that my hack is not feasible in any version of python after 2.6 (😮). (My hack involved overriding JSONEncoder._iterencode, which does not exist in python >= 2.7.)

I see two ways forward:

1. Implement our own serializer (more or less from scratch.)
2. Find some other external JSON/javascript-serializer that will work for us. (I’m not sure that such a thing exists.)

I’m not sure that either is worth the effort.

Thoughts/Ideas? (Questions?)

Would you please create a new PR with your new branch against master here, and mark it as "Draft"?

Also do you have a link to your hack via json.JSONEncoder you mention?

Also we will support only Python 3.5+ going forward.

Does this thread describe the same issue https://stackoverflow.com/a/53848267/2214933?

Does jsons do what is needed?

@stevepiercy New PR draft created: #413

My hacked up version of JSONEncoder is JSONConfigSerializer in widget.py, which works with the new literal_js marker class which is defined just above it. The two unit tests which are currently failing on #413 are a result of these hacks not working in recent versions of python.